[レポート]AWS Networking Roadshow – Japanに参加してきました

AWS Networking Roadshow - Japan というAWS主催の勉強会に参加してきたのでそのレポートをお送りします。

#AWS

#AWS Network Firewall

#AWS Cloud WAN

#Amazon VPC

#VPC Lattice

とーち

2023.08.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

お疲れさまです。とーちです。
AWS Networking Roadshow - Japan というAWS主催の勉強会に参加してきたのでそのレポートをお送りします。１日がかりのイベントでAWSの最新のネットワーキングサービスをキャッチアップできるイベントになっていました。

AWS Networking Roadshow - JapanAWS ネットワーキングロードショー — 日本 - Splash

TKP品川カンファレンスセンターANNEXで開催されました。品川駅から歩いて１０分かからない場所です。

Schedule

10:30 - 10:40　オープニング
10:40 - 12:15　キーノート：今後の AWS Networking
- AWS,WW Tech Leader, Networking Steve Seymour
1:15 - 2:00　グローバルネットワーク展開、DR対策を迅速化するAWS Cloud WAN（大阪リージョンも対応！）
- アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト山本様、小林様
2:05 - 3:05　AWS Transit Gatewayハンズオン
3:10 - 3:55　AWSネットワークを守るファイアウォールの設計パターン
- アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト山下様、山田様
4:10 - 4:55　柔軟にマイクロサービスを運用管理する－ Amazon VPC Lattice基本のキ
- アマゾンウェブサービスジャパン合同会社ソリューションアーキテクト須藤様
4:55 - 5:25　クロージング

キーノート Cloud Networking Innovation

AWS本国のAWS Networking Teamのsteve seymourさんによるキーノートです。
AWSグローバルインフラのコンセプトとしてリージョンやローカルゾーン等の６つの要素があるという話から始まり、リージョンの高可用性、スケーラビリティ、耐障害性を確保するためにどのような考えのもとAZが設計されているかといったような説明がありました。AZをグローバルネットワークにつなげるためにトランジットセンターというものが各リージョンに最低２つは存在しているという話があったのですが、トランジットセンターという存在を初めて知ったので興味深かったです。

それからVPCの歴史についてのお話がありました。開始当初のVPCはインターネットに接続する機能を有していなかったそうです。
顧客のAWS活用が進みVPCが多く使われていくに従って、VPC同士の接続のニーズが増えVPCピアリング、AWS Transit Gateway（以下TGW）というサービスが生まれてきたことなどが説明されました。
またTGW等の他にもAWSは様々なサービスを生み出しており、その例としてservice meshを開発者が容易に実現するためのAmazon VPC Lattice、ゼロトラストを実現するためのAWS Verified Access、顧客ネットワーク（wan）の課題を解決するためのAmazon AWS Cloud WAN等についての説明がありました。

グローバルネットワーク展開、DR対策を迅速化するAWS Cloud WAN（大阪リージョンも対応！）

AWS Cloud WAN（以下Cloud WAN）の概要を説明するセッションです。従来のエンタープライズが使用するWANではネットワーク全体のポリシーの管理、拠点追加時にリードタイムが発生することなどが課題として挙げられており、Cloud WANではそういった課題を解決できるとのことでした。 Cloud WANの概要として以下のような特徴が挙げられていました。

ポリシーベースの管理
セキュリティ
ダッシュボード
拠点間接続

また、ユースケースとしては以下を想定しているとのことです。

リージョンをまたがるVPC間通信
- リージョンをまたがってルートテーブルが動作する
- ネットワーク全体をセグメンテーションできる
- 特定のセグメント間は通信させないなどネットワーク全体のポリシーを制御できる
WAN接続
- Site-to-Site VPN やSDWANをつかったAWSへの接続をCloud WANをhubとして集約できる
ハイブリッド構成
- 上記のVPC及びWAN接続（SDWAN等）をCloud WANでまとめるようなハイブリッド構成も可能

また、Cloud WANのコンポーネントについての説明もありました。

coreNetwork：どのリージョンを含めるか。リージョンの集合体ともいえる。coreNetworkに対して設定を適用する
セグメント：coreNetwork内のルートテーブルを分離、例えば開発・本番などでセグメントを分ける
アタッチメント
- Transit Gatewayアタッチメントと似たようなもの
- アタッチメントする際にどのセグメントに所属させるかを指定
core Network policy
- ネットワーク全体のポリシーを定義
- 各セグメントへのアタッチメントポリシーやルーティングポリシー等を定義する
ダッシュボード
- coreNetwork全体を一元管理できる
- イベント一覧、トポロジ情報、ルーティング情報などを閲覧可能

その後、QAがありましたが、いくつか興味深いものがあったのでこちらも載せておきます

Cloud WANでは、Direct Connectは直接サポートされてない
- TGW（Direct Connect接続したもの）を介して接続することは可能
TGWとCloud WANの比較
- Cloud WAN採用のモチベーションの一つにTGWのピアリング管理を楽にしたいというケースがある
- Staticルートが多すぎて管理が煩雑というケース
- 東京と大阪だけの場合はTGWだけでも十分なケースはある
- 3,4箇所のリージョンのルーティングが出てくるとCloud WANも選択肢に出てくる

AWS Transit Gatewayハンズオン

Transit Gatewayのハンズオンが行われました。
Transit Gatewayを作成して実際に、あるVPCから別のVPCに通信を通す、あるVPCからアウトバウンド用に設定したVPCにTransit Gatewayを経由してインターネットに通信を出すといったことを行いました。

なお、ハンズオン資料はこちらからダウンロード可能です。 AWS Transit Gatewayハンズオン資料

このように複数VPCのインターネット通信を一つのアウトバウンド用VPCに集約するという設計パターンはよく見られるものですが、この構成の注意点として、インターネット宛の通信のソースIPがAWS所有のものになってしまうという点があるとのことです。サイトやサービスによってはAWS等のクラウドサービスが所有するIPアドレスをブロックしてしまうものがあるため、ソースIPがAWSのものになってしまうとそういったサイトと通信できないといったことが発生します。基本的に相手側のアクセス制御ポリシーで制限されてしまっているのでAWS側からどうにかする術はないのですが、こういった状況はクラウドへの理解が進むにつれてじょじょに改善していくのではとのことでした。

ネットワークを守るFW設計パターン

VPCにおけるファイアウォールとしては以下の３つがあるという説明から始まりました。

SecurityGroup、NetworkACL
ファイアウォール
- AWS Network Firewall
- パートナーソリューション

またAWS Network Firewallの特徴の説明がありました。

VPC内にAWSマネージドFWを導入するもの
１００Gbpsスループット対応
ステートフル/ステートレスのパケットフィルタ
脅威インテリジェンスデータに基づくAWSマネージドルールも使える
AWS Network Firewallのエンドポイントを通過する通信が検査対象となる
AWSマネージドルールグループ：セキュリティ脅威に関する最新情報にもとづいたIDS/IPSのルールをAWSが提供
- ドメインリストルールグループ
  - http,httpsで望ましくない相手と通信してないかをチェック
  - レピュテーションが低いドメイン
  - マルウェア、ボットネットに登録されているドメイン
- 脅威シグネチャルール
  - 既知の脆弱性に関する攻撃から防御する
  - マルウェア、ワームリクエストの識別

パートナーソリューションについては大きく分けて以下の２つのパターンがあります。

ホスト型
- AMIなどの形でセキュリティアプライアンスを購入しEC2にデプロイする形
- アプライアンス自体の機能の設定等に加えてEC2のデプロイと運用も利用者責任になる
FWaaS型
- ファイアウォールはAWSパートナーが構築運用しているものを利用
- ソリューションの購入や機能の設定などの対応が利用者側には必要

またパートナーソリューションを選定する際にはソリューションごとの機能の比較はもちろんですが、以下のようなポイントも検討したほうがよいとのことでした。

ホスト型かFWaaS型か
- サーバ構築運用：ホスト型ではEC2等のサーバ自体の構築運用が必要、FWaaSでは不要
- FWルールの管理：サービスによってかわるので一概に言えないが、ホスト型だと利用者が管理する場合が多い、FWaaSだとパートナーがマネージドルールを提供することもある
- コスト：ホスト型のほうはEC2インスタンス料金が追加でかかる
- 通信内容機密性：ホスト型は通信を自社AWSアカウント内に留められる、FWaaSではパートナーのVPCに一旦通信がいくのでシステム要件によっては注意
- パフォーマンス：ホスト型はEC2のサイジングが必要、FWaaSでは基本的に意識する必要はないが、リクエスト量による従量課金等の形で表れてくる

AWS Network Firewallとパートナーソリューションの使い分けについての説明もありました。

AWS Network Firewallが向くケース
- AWSマネージド・サービスが要件
- シンプル機能のみで十分
- AWSで一元的にサポートを受けたい
パートナーソリューションが向くケース
- 既に利用している製品をそのまま使いたい
- AWS Network Firewallでは機能が十分でない場合

私はAWS Network Firewallを実際に設計したことはなかったので、パートナーソリューションとの使い分けの勘所等を知ることができたのは良かったです。

柔軟にマイクロサービスを運用管理する－ Amazon VPC Lattice基本のキ

マイクロサービスの登場の背景から始まり、マイクロサービス独自の課題としてサービス間の通信を設計する必要があるということ、また設計するに当たってネットワーク管理者と開発者ではそれぞれ気にする点が違うため、VPC Lattice以前のAWSのソリューションでは、以下のようなネットワーク管理者と開発者の要望を同時に満たすことができないという話がありました。

ネットワーク管理者
- 組織のセキュリティ基準をみたす中央管理ツールが必要
開発者
- NWを扱いたくない
- しかしサービスの問題判別に役立つログなどの情報はほしい

そこで登場したのがVPC Latticeです。以下がVPC Latticeの概要です。

VPCをまたがるhttp/httpsを中継するサービス
ルートテーブルの設定は不要
サービスとサービスネットワーク
- 開発者は１つのサービスコンポーネントをVPC Latticeの「サービス」として定義する
- 管理者はサービスネットワークを定義する
  - サービスネットワークは論理的要素。定義したサービスを関連づける
  - 一つのサービスは複数のサービスネットワークに紐付けることもできる
- サービスネットワークをサービスを利用するVPCに関連づける
- VPCからはサービスネットワークに属すサービスへの通信が可能になる
- 注意点
  - 現時点では一つのVPCに一つのサービスネットワークしか関連付けできない
  - サービスの利用パターンごとにサービスネットワークを設計する

またVPC Latticeは以下のような機能を持っています。

ロードバランシング機能
- ALBとかなり似ている
- サービスの中で通信を受け入れるポートをリスナーとして設定
- リスナーごとにターゲットグループ（宛先）設定
- ターゲットグループ内でロードバランシングされる
- パスベースルーティングも可能
- ヘルスチェック機能もサポートしており正常ターゲットにのみ通信
認証とログ管理
- 認証
  - サービス、サービスネットワーク単位で認証ポリシーを設定可能
  - IAMの認証ポリシーを設定
  - サービスネットワークを管理するNW管理者が全体で最低限の統制をかけ、開発者がサービスごとの詳細なアクセス権限を設定するといったこともできる
  - アクセス元のVPCではセキュリティグループでの制御も可能
- アクセスログ
  - サービス、サービスネットワークの単位でログの設定が可能
  - 管理者と開発者がそれぞれの要件に基づいて設定可能
  - CloudWatch logs,s3,firehoseをログ出力先としてサポート

VPC Latticeをネットワーク管理者と開発者の観点でお話されていたのがとても勉強になりました。 VPC Latticeの責任分界点として、サービスネットワークまでがネットワーク管理者、サービスが開発者が管理するということが示されており、今後VPC Latticeを設計する際の指針と出来そうだと感じました。